• Fix FBC remove operation to only pass DB-backed operators to opm registry rm
• Update multiple security and non-security dependencies to latest versions
• Release version 9.5.2 with dependency updates and bug fixes
• Add fullsend AI workflow configuration for per-repo installation mode

Fix FBC remove to use only DB-backed operators

iib/workers/tasks/build.py

Update FBC remove test with DB operators validation

tests/test_workers/test_tasks/test_build.py

Bump version to 9.5.2

setup.py

Description

The workflow calls an external reusable workflow pinned to the mutable ref @v0 while granting
broad write permissions and passing secrets, so if that tag is retargeted the called workflow can
run arbitrary steps with this repo's token/OIDC and exfiltrate secrets. This can lead to repository
compromise (contents/issues/PR writes) and cloud credential abuse (id-token: write).

Code

.github/workflows/fullsend.yaml[R17-52]

+permissions:
+  actions: write
+  id-token: write
+  contents: write
+  issues: write
+  packages: read
+  pull-requests: write
+
+on:
+  issues:
+    types: [opened, edited, labeled]
+  issue_comment:
+    types: [created]
+  pull_request_target:
+    types: [opened, synchronize, ready_for_review, closed]
+  pull_request_review:
+    types: [submitted]
+
+jobs:
+  dispatch:
+    concurrency:
+      group: fullsend-dispatch-${{ github.event.issue.number || github.event.pull_request.number }}
+      cancel-in-progress: false
+    if: >-
+      github.event_name != 'issue_comment'
+      || github.event.comment.user.type != 'Bot'
+    uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0
+    with:
+      event_action: ${{ github.event.action }}
+      install_mode: per-repo
+      mint_url: ${{ vars.FULLSEND_MINT_URL }}
+      gcp_region: ${{ vars.FULLSEND_GCP_REGION }}
+    secrets:
+      FULLSEND_GCP_WIF_PROVIDER: ${{ secrets.FULLSEND_GCP_WIF_PROVIDER }}
+      FULLSEND_GCP_PROJECT_ID: ${{ secrets.FULLSEND_GCP_PROJECT_ID }}
+

Evidence

The workflow grants broad write permissions and passes secrets to a reusable workflow referenced by
a mutable external tag, which directly creates a supply-chain execution path with high privileges in
this repository’s context.

.github/workflows/fullsend.yaml[17-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`.github/workflows/fullsend.yaml` invokes a reusable workflow from `fullsend-ai/fullsend` using a mutable tag (`@v0`) while also granting broad write permissions and passing secrets. If the external tag is ever moved (malice/compromise), the new workflow content would execute in this repo context with these privileges and could exfiltrate secrets.

### Issue Context
- The called workflow is external (`fullsend-ai/fullsend`) and the ref is not immutable.
- The job inherits broad permissions (`contents: write`, `id-token: write`, etc.) and forwards GCP-related secrets.

### Fix Focus Areas
- .github/workflows/fullsend.yaml[17-52]

### Suggested fix
1. Pin the reusable workflow to an immutable commit SHA (preferred) instead of `@v0`, e.g.:
  - `uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@<full_sha>`
2. Move permissions to the job level and reduce to the minimum required for dispatch (avoid `contents: write` / `id-token: write` unless strictly necessary).
3. Pass only the secrets that are required for the dispatch stage (and consider environment protection if OIDC is needed).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

For /fs-fix-stop comments, the dispatch job still runs because its condition allows any non-bot
issue_comment, causing an unnecessary external dispatch invocation for an event that is already
handled by stop-fix. This adds avoidable workflow activity and can create confusing duplicate
automation for the same comment.

Code

.github/workflows/fullsend.yaml[R40-65]

+    if: >-
+      github.event_name != 'issue_comment'
+      || github.event.comment.user.type != 'Bot'
+    uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0
+    with:
+      event_action: ${{ github.event.action }}
+      install_mode: per-repo
+      mint_url: ${{ vars.FULLSEND_MINT_URL }}
+      gcp_region: ${{ vars.FULLSEND_GCP_REGION }}
+    secrets:
+      FULLSEND_GCP_WIF_PROVIDER: ${{ secrets.FULLSEND_GCP_WIF_PROVIDER }}
+      FULLSEND_GCP_PROJECT_ID: ${{ secrets.FULLSEND_GCP_PROJECT_ID }}
+
+  stop-fix:
+    if: >-
+      github.event_name == 'issue_comment'
+        && github.event.issue.pull_request
+        && github.event.comment.user.type != 'Bot'
+        && github.event.comment.body == '/fs-fix-stop'
+        && (
+          github.event.comment.author_association == 'OWNER'
+          || github.event.comment.author_association == 'MEMBER'
+          || github.event.comment.author_association == 'COLLABORATOR'
+          || github.event.comment.author_association == 'CONTRIBUTOR'
+          || github.event.comment.user.login == github.event.issue.user.login
+        )

Evidence

The dispatch job condition is satisfied for any non-bot issue comment, and /fs-fix-stop is a
non-bot issue comment that also satisfies the stop-fix condition, so both jobs will run for that
command.

.github/workflows/fullsend.yaml[40-65]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The `dispatch` job runs on all non-bot `issue_comment` events, including the `/fs-fix-stop` command comment that is specifically handled by the `stop-fix` job. This causes an unnecessary call to the external reusable dispatch workflow for the stop command.

### Issue Context
- `dispatch.if` allows any non-bot `issue_comment`.
- `stop-fix.if` is also true for the same `/fs-fix-stop` event.

### Fix Focus Areas
- .github/workflows/fullsend.yaml[40-65]

### Suggested fix
Refine the `dispatch` job `if:` to exclude `/fs-fix-stop` comments, e.g.:
```yaml
if: >-
 github.event_name != 'issue_comment'
 || (
   github.event.comment.user.type != 'Bot'
   && github.event.comment.body != '/fs-fix-stop'
 )
```
This keeps normal comment dispatching while ensuring the stop command only runs the `stop-fix` job.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools